Eagles Nest BBS 6/Eagles_Nest_Mac_Collection_Disc_6.TOAST/Other Macintosh Text/HowToCrackAt/How_to_Crack

Text File | 1990-10-02 | 23KB | 427 lines

====== Mac Cracking- A series on deprotection methods on the Macintosh =======
====== Written by The Atom / Spring 1986


Here it is.. First in the series of the Infamous Atom's mac crack series..

Some of you may have macs, others just wonder how you crack on the mac..
In this series I'll attempt to show you the basics of cracking on a mac
and hopefully give you an idea of the difficultly and difference between
apple and mac cracking.

1) Things that make mac cracking easier than apple:

  A) All code segments must be stored on the disk in normal format. No
     abnormal headers or anything that cannot be read with the normal
     ROM read routine.(data can be stored otherwise though)
  B) Protection on the mac has used fairly simple techniques since the
     programmers don't know all the tricks that they do on the II
  C) All disk I/O has to pass through the IWM chip and thus you can't have
     half and spiral tracking.

2) Things that make mac cracking harder than apple:

  A) No debugger(or monitor) in ROM.. Macsbug is a software debugger only and
     therefore can be destroyed by some nasty programs(EA does it on all
     of theirs)
  B) Programs have much more memory to play with. Instead of 0-$C000, you have
     $0-$400000 (  of course most of the top is ROM.)
  C) Virtually no documentation on non-standard read routines. Basically have
     to figure it out yourself.

The first thing you need to do before attempt a crack on the mac is learn
68000 assembly(duuh..).. WELL!! don't just look at it and assume you know
it!! You must really understand the addressing modes and especially how
the stack is handled. EVERYTHING on the mac uses the stack. The code you
are following is constantly calculating addresses and placing them on the
stack to RTS to.  Also, pick up a copy of Inside Mac.. So you can get a
basic Idea of the rom traps(there are over 300)

If you want to look for books, I suggest 68000 assembly by Leventhal.
And the Inside Mac phonebook or vol.1-3 from Apple

Next time I'll start showing you some traps, and a little 68000, then we'll
jump right in to the debugger and cracking a ware- Wizardry!

---------------------------------------------------------------------------

Welcome to part 2 of The Atom's guide to Mac cracking-

Today's Topic- 68000 assembly and Mac Traps

By now, I assume you have looked at the 68000 assembly language
somewhat and can at least understand small sections of code.
Just to clarify things, and teach you some machine-dependent ideas
(for the mac that is), I'll devote this part of the cracking series
to the 68000 and traps/interrupts.

First of all, the 68000 is a two instruction machine, unlike the
6502. This means that most commands have 2 arguments rather than
one(as the 6502 has).. IE> MOVE D0,#$1000 instead of STA #$1000.
This makes life much easier, especially with the use of multiple registers.
(68000 has 17, compared to the 4 on the 6502).
These registers are labelled D0-7, A0-7, and the processor status reg.
The registers starting with D are data registers which are 32 bits long.
You can store any kind of 32 bit number in them. The address registers,
(denoted by A), are also 32 bits long but can only refer to even numbered
addresses and are not valid for all modes.(Don't worry if it doesn't make
much sense, you'll get the hang of it)

Sooo.. Now we know about registers. How about operands? Unlike the 6502,
which has a different command for each register, the 68000 has a standard
set of commands which can work with all the regs. Instead of:
STA #$1000, STY #$1000, you would have MOVE D0,#$1000, MOVE D1,#$1000,
etc. The move (MOVE) command is the basic operand to move  data from
one place to another. Be it from reg to reg (mov d0,d1) or memory to memory
(mov #$1000,#$2000), or whatever.

Most of the other commands are similar to 6502, and work pretty much the
same(JSR,RTS,CMP,BEQ,BNE,etc.). There is one other addition to the syntax
you should know- the .b, .w, and .l suffixes.  These refer to byte, word, and
long word commands. By adding any of these to the end of an operand, you limit
the command to only that size of data. For instance, a MOVE.B D0,D1
would move the first 8 bits of D0 into the first 8 bits of D1. The word
command uses 16 bits, and long word uses 32. These can be added to most
commands that manipulate data, like CMP,CLR,MOV,ROL, etc. If you ignore the
syntax, it defaults to .w.

Now we get to Addressing modes: On the 6502, you had different syntax for
addressing, and its about the same on the 68000. An indirect
jump (JMP ($1000)) would become JMP ($1000)... really hard huh? or you can
use inderict in mov commands also- MOVE (A0),D1. This would move the
contents of whatever address was in A0 into D1.(IF $1000 was in A0, then
the contents of $1000 would go to D1). One note, the indirect mode can only
be used with the address registers, not the data registers.

Finally, there are the auto-increment and auto-decrement indirect modes.
If you did a MOVE (A0)+,D1, it would the contents of $1000 into d1, and then
automatically increment A0 so it now points to $1002.(It increments by 2
since it moved a word(16 bits) and each address points to a byte( in affect,
its now pointing to the next WORD)).  Auto-decrement works basically the
same way, a MOVE -(A0),D1, would decrement the address in A0 by 2, then
move the contents of $FFE into D1. The placement of the - or + is the way
its set up, so you can't do a MOV +(A0),D1 or MOV (A0)-,D1.

And a couple more sytnax things- there are no stack commands(PHA,etc.),they
use the auto-inc and auto-dec modes to implement a stack with the A7
register.  Its kind of complicated exactly how it works, so I won't go into it
here, but just assume that MOVE D0,-(A7) pushes D0 onto the stack and
MOVE (A7)+,D0 pops the value off the stack into D0. (the A7 is sometimes
replaced by SP as in MOVE D0,-(SP)).

So now we know everything there is to know about 68000 assembly, right?
Wrong... But we know enough to crack something!


But before I start talking about the debugger, I'll mention something about
the traps on the 68000. Since all ROM routines are called through these,
it pays to know what they are.

First of all, when the 68000 finds an opcode it doesnt know (some code that
doesnt translate into an executable instruction), it will look in a trap
table to see if there is a replacement code for it. This way, you can
implement your own 68000 commands by putting the address of your routine
into the trap table and simply issuing the command. On the mac, the trap
tables are in low memory and point to ROM routines.  Since the routines are
always in the same place with the same ROMS, the debugger keeps a table of
these traps and will actually name them for you in the code.. So while listing
a section of memory you may see something like this:

        _InitGraf
        _InitFonts
        _InitWindows
        Mov #14,D0
        Mov D0,-(SP)
        _Read

What it is doing is calling three rom routines to initialize different
sections of the window management, executing a couple of 68000 instructions
and then calling the Read ROM routine to read from the disk.  Fairly simple,
right? It does make cracking quite a bit easier, as long as you know what
most of the traps do. So be sure and have a copy of Inside Mac at hand when
you  start to debug/crack something.(and lots of paper)

Well, next time, we'll look at the debugger and start trying to crack
a few warez...

--------------------------------------------------------------------

Here we are again, with the 3rd installment of "Mac Cracking- man or myth?"
(or something like that).

The topic of discussion in this section will be the DEBUGGER.. Otherwise
known as MACSBUG.  If you end up doing much cracking at all, you'll begin
to love(and hate) some of macsbugs commands, and you should get fairly
familiar with reading other people's  68000 code.(or compiler code).

First, a couple notes about macsbug: To run it, you must have the macsbug
file on the disk you are booting up, and it must be named MACSBUG.. exactly,
(well, case doesnt matter, but otherwise, exactly like that ^^^).
If you are using the HFS system, it must be in the system folder along with
the system and finder files.  Also, don't forget to install the little
programmers switch in the side of your mac.. If you don't have it in, you
can't even start up macsbug!

Ok, well, I'll start by talking about how macsbug is loaded in, set up,
and then list some commands and show you some examples.

Booting up-  When the mac boots up, it reads a bunch of system related stuff
from the boot disks, initializes the font,quickdraw, resource and other
managers, and then throws up a Dialog saying "Welcome to Macintosh". It
then looks for a file name MACSBUG on the disk, and if it finds it, it
allocates some extra memory for it and then loads it in and sets it all up.
Macsbug takes up about 40k, so for large programs, running on a 128k, you
may not be able to load it.(get a 512k!)

Basically what macsbug does when it sets up is change a few pointers in
low ram that used to point to error routines to point to it. Like the
error when you hit the interrupt button on the side of the computer(plus
a few more). So now, when you hit the interrupt button, instead of getting
a bomb dialog, a new window will pop up, covering most of the screen, with
a dump of all the registers(d0-d7 and a0-a7 as well as the PC and some
other info).  You are now in Macsbug! You have stolen control of the 68000
from the executing program and can now debug(or crack) to your hearts
content.  But first, you need to know the macsbug commands!

Commands
--------

Macsbug has a lot of commands. At least 40. It basically works the same as
the monitor on a II, but with different syntax, and a bunch of nice tracing
functions. They are set up in a general format of a one or two word command,
followed by a few numeric parameters.

 What follows is a partial list of the basic commands we will be
using to crack Wizardry, and some explanation for each. To get a list of all
the commands, look in your Inside Mac manual under the section called
"INSIDE MACSBUG"(only in newer versions.)

Oh yea, forgot to mention, I'm using Macsbug V5.1. These commands work with
all versions 5.0 and higher.(you can check your version of macsbug by typing
DV <cr> at the prompt)

(aaaa = address, nnnn = number)

Memory Commands:

  DM aaaa nnnn          Display memory- gives you hex dump of the bytes
                        starting at aaaa and going up to address aaaa+nnnn
  ex. DM 0f00 10        Would dump out hex from $f00 to $f10
                        If you leave out the nnnn, it lists the next 16 bytes.
                        If you leave out aaaa, it starts at the current address.

  SM aaaa nn,nn1,nn2..  Set memory- changes value in address aaaa to nn, then
                        address aaaa+1 to nn1, etc.

  TD                    Total Display- dumps out all the registers, PC and
                        disassembles the current line

Break Commands:

  BR aaaa               Sets a break point at address aaaa. When the program
                        executes the line at aaaa, it will be interrupted and
                        the macsbug window will pop up.

  G aaaa                Just like the apple, starts execution at aaaa. If you
                        leave off aaaa, it starts where the PC last was.

  GT aaaa               Very nice command, starts executing at the PC, and then
                        stops and returns to macsbug when it gets to address
                        aaaa. (easier than setting breakpoints)

  T                     Trace, executes one instruction, then dumps out the
                        registers and disassembles the next line

  MR                    Magic return. If you are tracing along, and suddenly
                        encounter a JSR, you can type MR and it will execute
                        the subroutine and then return you to trace mode
                        right after it gets a RTS.

A Trap commands:

(these are probably the most important, be sure you understand them)

  AB TRAPNAME           Causes the computer to halt to return to macsbug when
                        it sees a TRAP command that is referred to by
                        TRAPNAME
ex. AB READ             This would stop the next time the program does a
                        READ call.

  AT TRAPNAME           Traces and displays the address of each call to the
                        trap TRAPNAME. Doesnt halt though.
ex. AT EJECT            Would show the address of each line that the program
                        executed that called the EJECT trap, and then continue
                        executing the program

  AX                    Clear all trap commands.(so it won't stop everytime it
                        does a READ anymore)

Disassembler commands:

  IL aaaa nnnn          List out disassembled code starting at address aaaa
                        and going until address aaaa+nnnn.. Just like the
                        L command on the II.
                        If you just enter IL <CR> it will list out the
                        next 10 or so instructions.

So those are all the commands you need to know! there are a bunch more, but
they aren't as powerful or easy to understand as these, so you can learn them
on your own.


Just to give you and example of using the debugger, I'll show the steps you
might use to find the starting address of a program:

1) put macsbug on the disk with the program you are trying to find the
   starting address for(Well call it PROGRAM)
2) Boot up the disk, and go to the desktop.
3) Press the interrupt button- you should see a big window pop up with a
   dump of the registers in it.
4) Type AB INITGRAF
   This tells macsbug to stop the next time it encounters an INITGRAF call.
   (initgraf is usually one of the first instructions applications run, so
    it will close to the starting address)
5) Hit G to start the finder running again.
6) Double click on PROGRAM and hope for the best!
7) If all goes ok, macsbug should pop up in a little while, displaying the
   address of the instruction that call INITGRAF.
8) Type IL aaaa, where aaaa is the address that macsbug said the initgraf
   instruction was at.
9) Thats it! the beginning of the code for our application! from there,
   we could trace on using the T command and watch the execution of the
   program. Or hit G to give the program back full control of the 68000.

Don't forget to do an AX command when you are done, otherwise you will be
jumping into macsbug everytime you run an application that calls INITGRAF.

Finally, I'd like to say something about macsbug alternatives:
I know of one great debugger called MCBUG. it works a lot like macsbug,
but has a few extra features that help a lot, like a built in mini-assembler,
some nice launch funtions, and a few other helpful commands. Its a shareware/
public domain program, so if you look around you should be able to find
a copy of it on compuserve or from a user group. It comes with docs, and
installs just like macsbug; simply rename it and boot!

---------------------------------------------------------------

Welcome to Part 4 of Mac Cracking- your guide to fame.

In this, the fourth, and hopefully final part, we will look at Wizardry and
actually remove its protection. Of course, as we all know, this is only for
backup purposes, right?

So first we need to set up a copy of the disk to work on. Wizardry is a
unusual protection, in that you can copy all the files off the disk, but
it asks you to put the master disk back in upon boot, and then reads some
bad blocks off of the master disk. The nice thing about this method is that
it does not crash the machine if it can't find the master, it simply
continues with a semi-demo game of Wiz. This saves a lot of time when you
are constantly backtracking and reloading the files to find the protection.

Here we go!

First, sector copy (or finder copy) the files from the wizardry disk onto
a blank. Then trash the Imagewriter file (we need more space for macsbug).
Copy macsbug onto the Wizardry disk, and then select the Wizardry file,
and install a minifinder with only Wizardry in the selection. This way, when
the disk boots up, we can set up some breakpoints while the minifinder is
running, and then execute Wizardry. If we let it boot straight into Wizardry,
we would have to guess when to hit the interrupt switch and hope that we
didn't miss something.

Now we have a disk to crack. Boot up the disk, and when you see the minifinder,
hit the interrupt switch. Macsbug should come up. Type AB INITGRAF <cr>.
This will find the starting address of the program by halting when it starts
initializing the managers. Now type G . You are back in the minifinder, so
double click on the wizardry file and wait for macsbug to regain control.

At this point, macsbug should appear saying it halted on a Initgraf call
at location F200 (this address will be different depending on your memory
size. F200 is on a 512 or plus). You can now type IL F200 to start listing
the code. As we look at the code (hit return to see another 20 lines after
you are done with a section) we see that the program contains no branching
until address F222. The protection check is going to involve reading a sector
from the disk and then branching on a result. So all we have to look for
is a branch after some disk access.

Type GT F222. Wizardry loads in some resources and sets up its menus and
windows. If you booted up your copy of wizardry normally, this is right before
it puts up a dialog and asks for the key disk. Now we have to narrow down
the search to a specific JSR. If you try GT F322, you see that it goes through
the check and comes back with a message that you did not insert the master
disk. This means that the JSR to the protection routine is somewhere between
F222 and F322. So now we look some more!

(If you did try the GT F322, you can type EA to exit to the application,
re-running Wizardry. It will abort again at the Initgraf, and then you
can type GT F222 to get back to where you belong)

By continuing this process(trying locations closer and closer to F222 in
the GT command) you will eventually find that the JSR to the protection
is at F31E. The program does not throw up a dialog saying you inserted the
wrong disk before this JSR, but does draw a dialog at F322, the next
statement. So we have tracked it down to a single JSR.. Now we can have fun.

If we trace, using the T command at this subroutine, we find that it
immediately executes a Loadseg trap. And then for some mysterious reason,
macsbug never regains control. This is the tricky part- After the JSR to
EFB7A (the loadseg), the program loads the protection routine from disk
AND loads code into EFB7A. Since the T command replaces the code at the
next instruction with a break command in order to regain control after
one step, this code is loaded on top of the break command, replacing it.
This is why your macsbug never comes back. There is not a break point to
interrupt the program any more!

What we can do though, is interrupt with the interrupt switch after it
brings up a dialog saying we inserted the wrong disk, and disassemble the
code that was loaded into EFB7A. When we look there, we see it did a
JMP to 13828. The code at 13828 was also loaded in with this loadseg trap,
so we didnt see it before. This is the main protection routine.

But now we have a problem- how do we stop the execution of the program at
13828 so we can trace the protection and find the correct branch? We can't
set a breakpoint at 13828 with GT, since it would get replaced with the
code during the Loadseg. And we can't stop it after the Loadseg since it
replaces itself and any breakpoints we set after it! What do we do??
Alas, macsbug comes through with yet another amazing command. ST .
This works like the GT, but does not set a breakpoint to stop the program.
(I'm not sure what it does to do this, but it uses the 68000 step flag)

So we get back to F31E (using the EA command as before, then the GT).
And type ST 13828. The reason we don't issue a ST right after F200 is
that the S commands slow execution of the program noticeably. You will have
to wait a couple of minutes for the ST 13828 to return to macsbug. (The
drive will make some strange noises, but don't worry.. just be patient)

After this hard work, we are now in trace mode at 13828. Hurrah! Almost
there. Be repeating the method we used to find the first JSR, and by
reading the code, you find that the last branch that seperates a key disk
dialog from the bad disk dialog is at 139D0. The BEQ +90 is executed if
the protection check comes out bad. If you search the code, you see that
the good code continues 3 instructions from the address the BEQ branches
to. So now we simply replace the BEQ with BRA +98, and no matter what the
protection check returns, everything continues fine.

Now to test a be sure our patch works. Boot the disk from scratch and get
to the trace mode at 13828 using the commands we used before. Now type
SM 139D0 60 00 00 98 . This is the code for a BRA +98, which we are replacing
at 139D0. Hit G, and there it is! Your copy should continue to load, and
no matter what disk you put in for the master, it will thank you for inserting
your "master" and continue along its merry way.

But we don't want to have to use macsbug to does this EVERY time we boot
up, so we'll change the program on the disk. First, dump the memory from
the instructions before and after the BEQ +90 and write them down. Then
run Fedit (its a sector editor program) and open the file Wizardry on your
cracking disk. Do a hex search for the values-
0A 00 00 01 67 00 00 90 30 2E FF F2
(These are the bytes surrounding the instruction that you wrote down earlier.
 By searching for the whole string, we are sure we have the correct
 Beq +92 in the program, in case there is more than one).
Go in to hex edit mode and replace the 67 00 00 90 with 60 00 00 98. And
write the sector back out.

Congratulations, you have successfully cracked Wizardry. You can copy the
Wizardry file you patched onto your master disk, or make the patch to a
sector copy of the original to get the disk back looking like it normally
did.(Auto boot into wizardry, no macsbug or minifi